The Simple Certificate Enrollment Protocol (SCEP) was developed by Verisign, Inc., of Restin, Va., for Cisco Systems, Inc., of San Jose, Calif., primarily to allow network administrators to easily enroll network computing devices for certificates in a scalable manner. Because these network computing devices are unlikely to have their identities represented in an enterprise directory or credential store, SCEP includes no provision for authenticating the identity of the requester. Instead, SCEP allows for two different authorization mechanisms. The first authorization mechanism is manual, where the requester is required to wait after submission for the Certification Authority (CA) administrator or certificate officer to approve the request. The second authorization method is pre-shared secret, where the SCEP server creates a “challenge password” that must be somehow delivered to the requester included with a submission back to the server.
The overall security model surrounding SCEP's creation is that of a relatively well-controlled environment. In the use cases which SCEP was initially designed to solve, challenge passwords are retrieved by a highly trusted CA administrator, and given to a highly trusted network administrator, to generate certificates for highly trusted network computing devices. In many cases, the SCEP challenge may well be retrieved and used by the same administrator.
Microsoft Corporation, of Redmond, Wash., has supported SCEP for its CA software since Windows Server 2003, first as freely downloadable add-on component, and then with Windows Server 2008 as a native component (via the Network Device Enrollment Service (NDES) role). Microsoft Corporation's SCEP implementation is relatively full featured, and allows for a variety of configuration options including: setting the length of the SCEP challenge passwords; turning the requirement of SCEP challenges on or off; allowing or disallowing the reuse of SCEP challenges; and setting the maximum time that an unused SCEP challenge should be considered valid.
When Apple Inc., of Cupertino, Calif., added SCEP to its mobile operating system (referred to as iOS) the global count of SCEP-speaking client computing devices was increased by several orders of magnitude. Additionally, it moved SCEP away from the security-friendly environment in which the protocol was initially used. Instead of using certificates to tightly controlled network computing devices under the direction of highly trusted administrators, it is now possible to architect systems that allow SCEP enrollment of “less-trusted” computing devices and their users, over the internet. In fact, many Mobile Device Management (MDM) systems rely on this type of architecture. This shift in possible security models is important, and will be further discussed below.
One critically important aspect of the SCEP challenge password is that, while it provides authorization to submit a PKCS#10 formatted certificate request, it does not actually authenticate the requestor, nor does it even identify them. Note that PKCS is a public-key cryptography standard produced by RSA Laboratories of Bedford, Mass. Furthermore, neither the SCEP challenge, nor the SCEP server itself, makes any statement about the type or content of the request that may be submitted. In essence, possession of a valid SCEP challenge password entitles the bearer to submit a certificate request with content entirely of their own choosing to the SCEP server. This is fine in the original “admin-only” security model for which SCEP was initially created, but is cause for concern when put to use on the internet at large.
It may be possible for a user or computing device to take their legitimately acquired SCEP challenge password, and use it to obtain a certificate that represents a different user or computing device with a higher level of access, or even to obtain a different type of certificate than what was intended. If the challenge passwords are reused or disabled, the consequences are even direr, as the attacker would not need to be a legitimate user.
This issue is not really the “fault” of Apple, Inc., Cisco Systems, Inc., Microsoft Corporation, or of the myriad of Mobile Device Management systems that leverage SCEP. Rather it was brought about by the combination of several factors. First, SCEP challenge passwords give someone permission to submit a certificate request to the SCEP server, but make no claims or enforcement over the content of that submission. Second, iOS operated computing devices' support of SCEP has opened up avenues for SCEP requests to originate from un-trusted networks, and from less-trusted (non-administrative) users, and many Mobile Device Management systems require this. Third, many enterprise CA installations, including most default installations of Microsoft Corporation's CA, are being used to issue certificates that serve as network authentication credentials. It's also important to note that the execution of the attack does not require the use of an Apple computing device—it only requires a valid SCEP challenge password, and the ability to communicate with the SCEP server. Thus, internally-developed SCEP servers, or servers protected by a reverse proxy or firewall are also susceptible. Accordingly, there is a need for an improved architecture for validating SCEP certificate enrollment requests.